Проектирование Базы данных

Сущность «Сведения о книгах» содержит информацию о всех книгах, имеющихся в библиотеке. Отдельный экземпляр этой сущности содержит информацию только об одной книге. Сущность «Учет выдачи» содержит информацию о конкретной книге, о том кто её взял, когда взял и когда вернет книгу. Между сущностью «Книги» и сущностью «Выдача книг» существует связь типа «1:М», которая означает, что любая книга, которая находиться в прокате, является обязательным по отношению к сущности «Книги». Сущность «Сведения о читателе» содержит информацию о читателях. Отдельный экземпляр этой сущности содержит информацию об одном читателе. Существует связь между сущностью «Сведения о читателе» и сущностью «Учет выдачи» типа «1:М», обязательная со стороны сущности «Сведения о читателе» (каждому экземпляру сущности «Учет выдачи» обязательно соответствует читатель и причем только один).
Определим ключи – уникальные идентификаторы экземпляров каждой сущности: для сущности «Сведения о книге» - это код книги, для сущности «Учет выдачи» - код выдачи, для сущности «Учет читателей» - код читателя.

Таблица 1- Сведения о типах сущностей

Имя сущности Описание Псевдоним Особенности использования
1 2 3 4
1. Сведения о книгах Основные сведения о книгах в библиотеке Книги Отдельный экземпляр этой сущности содержит информацию только об одной книге.
2. Сведения о читателях Основные данные о посетителях библиотеки Читатели Отдельный экземпляр этой сущности содержит информацию об одном читателе.
3. Учет выдачи Сведения о выдаче книг читателям Выдача Каждая книга может быть выдана любому читателю

Таблица 2 – Сведения о типах связи

Тип сущности Тип связи Тип сущности
1. Сведения о книгах Входят в состав Учет выдачи
2. Учет выдачи Содержит Сведения о книгах
3. Учет выдачи Содержит Сведения о читателях
4. Сведения о читателях берут Учет выдачи














Рисунок 2. Концептуальная модель предметной области «Библиотека»

Физическая модель БД

Физическая модель данных описывает данные средствами конкретной СУБД. Мы будем считать, что физическая модель данных реализована средствами именно реляционной СУБД. Отношения, разработанные на стадии формирования логической модели данных, преобразуются в таблицы, атрибуты становятся столбцами таблиц, для ключевых атрибутов создаются уникальные индексы, домены преображаются в типы данных, принятые в конкретной СУБД.
Ограничения, имеющиеся в логической модели данных, реализуются различными средствами СУБД, например, при помощи индексов, декларативных ограничений целостности, триггеров, хранимых процедур. При этом опять-таки решения, принятые на уровне логического моделирования определяют некоторые границы, в пределах которых можно развивать физическую модель данных. Точно также, в пределах этих границ можно принимать различные решения. Например, отношения, содержащиеся в логической модели данных, должны быть преобразованы в таблицы, но для каждой таблицы можно дополнительно объявить различные индексы, повышающие скорость обращения к данным. Многое тут зависит от конкретной СУБД.
При разработке физической модели данных возникают вопросы:
Хорошо ли спроектированы таблицы?
Правильно ли выбраны индексы?
Наконец, как результат предыдущих этапов появляется собственно сама база данных. База данных реализована на конкретной программно-аппаратной основе, и выбор этой основы позволяет существенно повысить скорость работы с базой данных.
Решения, принятые на каждом этапе моделирования и разработки базы данных, будут сказываться на дальнейших этапах. Поэтому особую роль играет принятие правильных решений на ранних этапах моделирования.